home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pppext-lcpext-03.txt < prev    next >
Text File  |  1993-08-13  |  37KB  |  1,323 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        W A Simpson
  8. Internet Draft                                                Daydreamer
  9. expires in six months                                        August 1993
  10.  
  11.  
  12.                            PPP LCP Extensions
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is the product of the Point-to-Point Protocol Working
  19.    Group of the Internet Engineering Task Force (IETF).  Comments should
  20.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24.    This document is an Internet Draft.  Internet Drafts are working
  25.    documents of the Internet Engineering Task Force (IETF), its Areas,
  26.    and its Working Groups.  Note that other groups may also distribute
  27.    working documents as Internet Drafts.
  28.  
  29.    Internet Drafts are draft documents valid for a maximum of six
  30.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  31.    other documents at any time.  It is not appropriate to use Internet
  32.    Drafts as reference material or to cite them other than as a
  33.    ``working draft'' or ``work in progress.''
  34.  
  35.    Please check the 1id-abstracts.txt listing contained in the
  36.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  37.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  38.    current status of any Internet Draft.
  39.  
  40. Abstract
  41.  
  42.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  43.    transporting multi-protocol datagrams over point-to-point links.
  44.  
  45.    PPP defines an extensible Link Control Protocol (LCP) for
  46.    establishing, configuring, and testing the data-link connection.
  47.    This document defines several additional LCP features which have been
  48.    suggested over the past year.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                  expires in six months                  [Page i]
  59. DRAFT                      PPP LCP extensions                August 1993
  60.  
  61.  
  62. 1.  Additional LCP Packets
  63.  
  64. The Packet format and basic facilities are already defined for LCP [1].
  65.  
  66. Up-to-date values of the LCP Code field are specified in the most recent
  67. "Assigned Numbers" RFC [2].  This specification concerns the following
  68. values:
  69.  
  70.    12      Identification
  71.    13      Time-Remaining
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Simpson                  expires in six months                  [Page 1]
  114. DRAFT                      PPP LCP extensions                August 1993
  115.  
  116.  
  117. 1.1.  Identification
  118.  
  119.    Description
  120.  
  121.       This Code provides a method for an implementation to identify
  122.       itself to its peer.  This Code might be used for many diverse
  123.       purposes, such as link troubleshooting, license enforcement, etc.
  124.  
  125.       Identification is a Link Maintenance packet.  Identification
  126.       packets MAY be sent at any time, including before LCP has reached
  127.       the Opened state.
  128.  
  129.       The sender transmits a LCP packet with the Code field set to 12
  130.       (Identification), the Identifier field set, the local Magic-Number
  131.       (if any) inserted, and the Message field filled with any desired
  132.       data, but not exceeding the default MRU minus eight.
  133.  
  134.       Receipt of an Identification packet causes the RXR or RUC event.
  135.       There is no response to the Identification packet.
  136.  
  137.       Receipt of a Code-Reject for the Identification packet SHOULD
  138.       generate the RXJ+ (permitted) event.
  139.  
  140.       Rationale:
  141.  
  142.          This feature is defined as part of LCP, rather than as a
  143.          separate PPP Protocol, in order that its benefits may be
  144.          available during the earliest possible stage of the Link
  145.          Establishment phase.  It allows an operator to learn the
  146.          identification of the peer even when negotiation is not
  147.          converging.  Non-LCP packets cannot be sent during the Link
  148.          Establishment phase.
  149.  
  150.          This feature is defined as a separate LCP Code, rather than a
  151.          Configuration-Option, so that the peer need not include it with
  152.          other items in configuration packet exchanges, and handle
  153.          "corrected" values or "rejection", since its generation is both
  154.          rare and in one direction.  It is recommended that
  155.          Identification packets be sent whenever a Configure-Reject is
  156.          sent or received, as a final message when negotiation fails to
  157.          converge, and when LCP reaches the Opened state.
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168. Simpson                  expires in six months                  [Page 2]
  169. DRAFT                      PPP LCP extensions                August 1993
  170.  
  171.  
  172.    A summary of the Identification packet format is shown below.  The
  173.    fields are transmitted from left to right.
  174.  
  175.     0                   1                   2                   3
  176.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  177.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  178.    |     Code      |  Identifier   |            Length             |
  179.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.    |                         Magic-Number                          |
  181.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.    |    Message ...
  183.    +-+-+-+-+-+-+-+-+
  184.  
  185.  
  186.    Code
  187.  
  188.       12 for Identification
  189.  
  190.    Identifier
  191.  
  192.       The Identifier field is one octet and is for use by the
  193.       Identification sender.
  194.  
  195.    Length
  196.  
  197.       >= 8
  198.  
  199.    Magic-Number
  200.  
  201.       The Magic-Number field is four octets and aids in detecting links
  202.       which are in the looped-back condition.  Until the Magic-Number
  203.       Configuration Option has been successfully negotiated, the Magic-
  204.       Number MUST be transmitted as zero.  See the Magic-Number
  205.       Configuration Option for further explanation.
  206.  
  207.    Message
  208.  
  209.       The Message field is zero or more octets, and its contents are
  210.       implementation dependent.  It is intended to be human readable,
  211.       and MUST NOT affect operation of the protocol.  It is recommended
  212.       that the message contain displayable ASCII characters 32 through
  213.       126 decimal.  Mechanisms for extension to other character sets are
  214.       the topic of future research.  The size is determined from the
  215.       Length field.
  216.  
  217.       Implementation Note:
  218.  
  219.          The Message will usually contain such things as the sender's
  220.  
  221.  
  222.  
  223. Simpson                  expires in six months                  [Page 3]
  224. DRAFT                      PPP LCP extensions                August 1993
  225.  
  226.  
  227.          hardware type, PPP software revision level, and PPP product
  228.          serial number, MIB information such as link speed and interface
  229.          name, and any other information that the sender thinks might be
  230.          useful in debugging connections.  The format is likely to be
  231.          different for each implementor, so that those doing serial
  232.          number tracking can validate their numbers.  A robust
  233.          implementation SHOULD treat the Message as displayable text,
  234.          and SHOULD be able to receive and display a very long Message.
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Simpson                  expires in six months                  [Page 4]
  279. DRAFT                      PPP LCP extensions                August 1993
  280.  
  281.  
  282. 1.2.  Time-Remaining
  283.  
  284.    Description
  285.  
  286.       This Code provides a mechanism for notifying the peer of the time
  287.       remaining in this session.
  288.  
  289.       The nature of this information is advisory only.  It is intended
  290.       that only one side of the connection will send this packet
  291.       (generally a "network access server").  The session is actually
  292.       concluded by the Terminate-Request packet.
  293.  
  294.       Time-Remaining is a Link Maintenance packet.  Time-Remaining
  295.       packets may only be sent in the LCP Opened state.
  296.  
  297.       The sender transmits a LCP packet with the Code field set to 13
  298.       (Time-Remaining), the Identifier field set, the local Magic-Number
  299.       (if any) inserted, and the Message field filled with any desired
  300.       data, but not exceeding the peer's established MRU minus twelve.
  301.  
  302.       Receipt of an Time-Remaining packet causes the RXR or RUC event.
  303.       There is no response to the Time-Remaining packet.
  304.  
  305.       Receipt of a Code-Reject for the Time-Remaining packet SHOULD
  306.       generate the RXJ+ (permitted) event.
  307.  
  308.       Rationale:
  309.  
  310.          This notification is defined as a separate LCP Code, rather
  311.          than a Configuration-Option, in order that changes and warning
  312.          messages may occur dynamically during the session, and that the
  313.          information might be determined after Authentication has
  314.          occurred.  Typically, this packet is sent when the link enters
  315.          Network-Layer Protocol phase, and at regular intervals
  316.          throughout the session, particularly near the end of the
  317.          session.
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Simpson                  expires in six months                  [Page 5]
  334. DRAFT                      PPP LCP extensions                August 1993
  335.  
  336.  
  337.    A summary of the Time-Remaining packet format is shown below.  The
  338.    fields are transmitted from left to right.
  339.  
  340.     0                   1                   2                   3
  341.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  342.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  343.    |     Code      |  Identifier   |            Length             |
  344.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  345.    |                         Magic-Number                          |
  346.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  347.    |                       Seconds-Remaining                       |
  348.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  349.    |    Message ...
  350.    +-+-+-+-+-+-+-+-+
  351.  
  352.  
  353.    Code
  354.  
  355.       13 for Time-Remaining
  356.  
  357.    Identifier
  358.  
  359.       The Identifier field is one octet and is for use by the Time-
  360.       Remaining sender.
  361.  
  362.    Length
  363.  
  364.       >= 12
  365.  
  366.    Magic-Number
  367.  
  368.       The Magic-Number field is four octets and aids in detecting links
  369.       which are in the looped-back condition.  Until the Magic-Number
  370.       Configuration Option has been successfully negotiated, the Magic-
  371.       Number MUST be transmitted as zero.  See the Magic-Number
  372.       Configuration Option for further explanation.
  373.  
  374.    Seconds-Remaining
  375.  
  376.       The Seconds-Remaining field is four octets and indicates the
  377.       number of integral seconds remaining in this session.  This 32 bit
  378.       unsigned value is sent most significant octet first.  A value of
  379.       0xffffffff (all ones) represents no timeout, or "forever".
  380.  
  381.    Message
  382.  
  383.       The Message field is zero or more octets, and its contents are
  384.       implementation dependent.  It is intended to be human readable,
  385.  
  386.  
  387.  
  388. Simpson                  expires in six months                  [Page 6]
  389. DRAFT                      PPP LCP extensions                August 1993
  390.  
  391.  
  392.       and MUST NOT affect operation of the protocol.  It is recommended
  393.       that the message contain displayable ASCII characters 32 through
  394.       126 decimal.  Mechanisms for extension to other character sets are
  395.       the topic of future research.  The size is determined from the
  396.       Length field.
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443. Simpson                  expires in six months                  [Page 7]
  444. DRAFT                      PPP LCP extensions                August 1993
  445.  
  446.  
  447. 2.  Additional LCP Configuration Options
  448.  
  449. The Configuration Option format and basic options are already defined
  450. for LCP [1].
  451.  
  452. Up-to-date values of the LCP Option Type field are specified in the most
  453. recent "Assigned Numbers" RFC [2].  This document concerns the following
  454. values:
  455.  
  456.    9       FCS-Alternatives
  457.    10      Self-Describing-Padding
  458.    13      Callback
  459.    15      Compound-Frames
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498. Simpson                  expires in six months                  [Page 8]
  499. DRAFT                      PPP LCP extensions                August 1993
  500.  
  501.  
  502. 2.1.  FCS-Alternatives
  503.  
  504.    Description
  505.  
  506.       This Configuration Option provides a method for an implementation
  507.       to specify another FCS format to be sent by the peer, or to
  508.       negotiate away the FCS altogether.
  509.  
  510.       This option is negotiated separately in each direction.  However,
  511.       it is not required that an implementation be capable of
  512.       concurrently generating a different FCS on each side of the link.
  513.  
  514.       The negotiated FCS values take effect only during Authentication
  515.       and Network-Layer Protocol phases.  Frames sent during any other
  516.       phase MUST contain the default FCS.
  517.  
  518.    A summary of the FCS-Alternatives Configuration Option format is
  519.    shown below.  The fields are transmitted from left to right.
  520.  
  521.     0                   1                   2
  522.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  523.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  524.    |     Type      |    Length     |    Options    |
  525.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  526.  
  527.  
  528.    Type
  529.  
  530.       9
  531.  
  532.    Length
  533.  
  534.       3
  535.  
  536.    Options
  537.  
  538.       This field is one octet, and is comprised of the "logical or" of
  539.       the following values:
  540.  
  541.           1   Null FCS
  542.           2   CCITT 16-bit FCS
  543.           4   CCITT 32-bit FCS
  544.  
  545.  
  546.    Implementation Note:
  547.  
  548.       For most PPP HDLC framed links, the default FCS is the CCITT 16-
  549.       bit FCS.  Some framing techniques and high speed links may use
  550.  
  551.  
  552.  
  553. Simpson                  expires in six months                  [Page 9]
  554. DRAFT                      PPP LCP extensions                August 1993
  555.  
  556.  
  557.       another format as the default FCS.
  558.  
  559.  
  560. 2.1.1.  LCP considerations
  561.  
  562.    The link can be subject to loss of state, and the LCP can re-
  563.    negotiate at any time.  When the LCP begins renegotiation or
  564.    termination, it is recommended that the LCP Configure-Request or
  565.    Terminate-Request packet be sent with the last negotiated FCS, then
  566.    change to the default FCS, and a duplicate LCP packet is sent with
  567.    the default FCS.  The packet identifier SHOULD NOT be incremented for
  568.    each such duplicate packet.
  569.  
  570.    On receipt of a LCP Configure-Request or Terminate-Request packet,
  571.    the implementation MUST change to the default FCS for both
  572.    transmission and reception.  If the Request packet received contains
  573.    a duplicate Identifier field, it SHOULD be silently discarded.
  574.  
  575.    Implementation Notes:
  576.  
  577.       The need to send two packets is only necessary after the
  578.       Alternative-FCS has already been negotiated.  It need not occur
  579.       during state transitions when there is a natural indication that
  580.       the default FCS is in effect, such as the Down and Up events.  It
  581.       is necessary to send two packets in the Ack-Sent and Opened
  582.       states, since the peer could mistakenly believe that the link has
  583.       Opened.
  584.  
  585.       It is possible to send a single 48-bit FCS which is a combination
  586.       of the 16-bit and 32-bit FCS.  This may be sent instead of sending
  587.       the two packets described above.  We have not standardized this
  588.       procedure because of intellectual property concerns.  If such a
  589.       48-bit FCS is used, it MUST only be used for LCP packets.
  590.  
  591.  
  592. 2.1.2.  Null FCS
  593.  
  594.    The Null FCS SHOULD only be used for those network-layer and
  595.    transport protocols which have an end-to-end checksum available, such
  596.    as TCP/IP, or UDP/IP with the checksum enabled.  That is, the Null
  597.    FCS option SHOULD be negotiated together with another non-null FCS
  598.    option in a heterogeneous environment.
  599.  
  600.    When a configuration (LCP or NCP) or authentication packet is sent,
  601.    the FCS MUST be included.  When a configuration (LCP or NCP) or
  602.    authentication packet is received, the FCS MUST be verified.
  603.  
  604.    There are several cases to be considered:
  605.  
  606.  
  607.  
  608. Simpson                  expires in six months                 [Page 10]
  609. DRAFT                      PPP LCP extensions                August 1993
  610.  
  611.  
  612.    Null FCS alone
  613.  
  614.       The sender generates the FCS for those frames which require the
  615.       FCS before sending the frame.
  616.  
  617.       When a frame is received, it is not necessary to check the FCS
  618.       before demultiplexing.  Any FCS is treated as padding.
  619.  
  620.       Receipt of an Authentication or Control packet would be discovered
  621.       after passing the frame to the demultiplexer.  Verification of the
  622.       FCS can easily be accomplished using one of the software
  623.       algorithms defined in PPP HDLC Framing [3] (16-bit FCS) and
  624.       Appendix A (32-bit FCS).
  625.  
  626.    Null FCS with another FCS, using software
  627.  
  628.       This is similar to the above case.
  629.  
  630.       Those packets which are required to have the FCS (Authentication,
  631.       Control, or Network-Protocols lacking a checksum) are checked
  632.       using software after demultiplexing.  Packets which fail the FCS
  633.       test are discarded as usual.
  634.  
  635.    Null FCS with another FCS, using hardware
  636.  
  637.       A flag is passed with the frame, indicating whether or not it has
  638.       passed the hardware FCS check.  The incorrect FCS MUST be passed
  639.       with the rest of the data.  The frame MUST NOT be discarded until
  640.       after demultiplexing, and only those frames that require the FCS
  641.       are discarded.
  642.  
  643.    All three FCS forms (Null, 16 and 32) may be used concurrently on
  644.    different frames when using software.  That is probably not possible
  645.    with most current hardware.
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663. Simpson                  expires in six months                 [Page 11]
  664. DRAFT                      PPP LCP extensions                August 1993
  665.  
  666.  
  667. 2.2.  Self-Describing-Padding
  668.  
  669.    Description
  670.  
  671.       This Configuration Option provides a method for an implementation
  672.       to indicate to the peer that it understands self-describing pads
  673.       when padding is added at the end of the PPP Information field.
  674.  
  675.       This option is most likely to be used when some protocols, such as
  676.       network-layer or compression protocols, are configured which
  677.       require detection and removal of any trailing padding.  Such
  678.       special protocols are identified in their respective documents.
  679.  
  680.       If the option is Rejected, the peer MUST NOT add any padding to
  681.       the identified special protocols, but MAY add padding to other
  682.       protocols.
  683.  
  684.       If the option is Ack'd, the peer MUST follow the procedures for
  685.       adding self-describing pads, but only to the specifically
  686.       identified protocols.  The peer is not required to add any padding
  687.       to other protocols.
  688.  
  689.       Implementation Notes:
  690.  
  691.          This is defined so that the Reject handles either case where
  692.          the peer does not generate self-describing pads.  When the peer
  693.          never generates padding, it may safely Reject the option.  When
  694.          the peer does not understand the option, it also will not
  695.          successfully configure a special protocol which requires
  696.          elimination of pads.
  697.  
  698.          While some senders might only be capable of adding padding to
  699.          every protocol or not adding padding to any protocol, by design
  700.          the receiver need not examine those protocols which do not need
  701.          the padding stripped.
  702.  
  703.          To avoid unnecessary configuration handshakes, an
  704.          implementation which generates padding, and has a protocol
  705.          configured which requires the padding to be known, SHOULD
  706.          include this Option in its Configure-Request, and SHOULD
  707.          Configure-Nak with this Option when it is not present in the
  708.          peer's Request.
  709.  
  710.       Each octet of self-describing pad contains the index of that
  711.       octet.  The first pad octet MUST contain the value one (1), which
  712.       indicates the Padding Protocol to the Compound-Frames option.
  713.       After removing the FCS, the final pad octet indicates the number
  714.       of pad octets to remove.  For example, three pad octets would
  715.  
  716.  
  717.  
  718. Simpson                  expires in six months                 [Page 12]
  719. DRAFT                      PPP LCP extensions                August 1993
  720.  
  721.  
  722.       contain the values 1, 2, 3.
  723.  
  724.       The Maximum-Pad-Value (MPV) is also negotiated.  Only the values 1
  725.       through MPV are used.  When no padding would otherwise be
  726.       required, but the final octet of the PPP Information field
  727.       contains the value 1 through MPV, at least one self-describing pad
  728.       octet MUST be added to the frame.  If the final octet is greater
  729.       than MPV, no additional padding is required.
  730.  
  731.       Implementation Notes:
  732.  
  733.          If any of the pad octets contain an incorrect index value, the
  734.          entire frame SHOULD be silently discarded.  This is intended to
  735.          prevent confusion with the FCS-Alternatives option, but might
  736.          not be necessary in robust implementations.
  737.  
  738.          Since this option is intended to support compression protocols,
  739.          the Maximum-Pad-Value is specified to limit the likelihood that
  740.          a frame may actually become longer.
  741.  
  742.    A summary of the Self-Describing-Padding Configuration Option format
  743.    is shown below.  The fields are transmitted from left to right.
  744.  
  745.     0                   1                   2
  746.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  747.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  748.    |     Type      |    Length     |    Maximum    |
  749.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  750.  
  751.  
  752.    Type
  753.  
  754.       10
  755.  
  756.    Length
  757.  
  758.       3
  759.  
  760.    Maximum
  761.  
  762.       This field specifies the largest number of padding octets which
  763.       may be added to the frame.  The value may range from 1 to 255, but
  764.       values of 2, 4, or 8 are most likely.
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773. Simpson                  expires in six months                 [Page 13]
  774. DRAFT                      PPP LCP extensions                August 1993
  775.  
  776.  
  777. 2.3.  Callback
  778.  
  779.    Description
  780.  
  781.       This Configuration Option provides a method for an implementation
  782.       to request a dial-up peer to call back.  This option might be used
  783.       for many diverse purposes, such as savings on toll charges.
  784.  
  785.       When Callback is successfully negotiated, and authentication is
  786.       complete, the Authentication phase proceeds directly to the
  787.       Termination phase, and the link is disconnected.
  788.  
  789.       Then, the peer re-establishes the link, without negotiating
  790.       Callback.
  791.  
  792.       Implementation Notes:
  793.  
  794.          A peer which agrees to this option SHOULD request the
  795.          Authentication-Protocol Configuration Option.  The user
  796.          information learned during authentication can be used to
  797.          determine the user location, or to limit a user to certain
  798.          locations, or merely to determine whom to bill for the service.
  799.  
  800.          Authentication SHOULD be requested in turn by the
  801.          implementation when it is called back, if mutual authentication
  802.          is desired.
  803.  
  804.    A summary of the Callback Option format is shown below.  The fields
  805.    are transmitted from left to right.
  806.  
  807.     0                   1                   2                   3
  808.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  809.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  810.    |     Type      |    Length     |   Operation   |  Message ...
  811.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  812.  
  813.  
  814.    Type
  815.  
  816.       13
  817.  
  818.    Length
  819.  
  820.       >= 3
  821.  
  822.    Operation
  823.  
  824.       The Operation field is one octet and indicates the contents of the
  825.  
  826.  
  827.  
  828. Simpson                  expires in six months                 [Page 14]
  829. DRAFT                      PPP LCP extensions                August 1993
  830.  
  831.  
  832.       Message field.
  833.  
  834.       0       location is determined by user authentication
  835.  
  836.       1       Dialing string, the format and contents of which assumes
  837.               configuration knowledge of the specific device which is
  838.               making the callback.
  839.  
  840.       2       Location identifier, which may or may not be human
  841.               readable, to be used together with the authentication
  842.               information for a database lookup to determine the
  843.               callback location.
  844.  
  845.       3       E.164 number.
  846.  
  847.       4       Distinguished name.
  848.  
  849.    Message
  850.  
  851.       The Message field is zero or more octets, and its general contents
  852.       are determined by the Operation field.  The actual format of the
  853.       information is site or application specific, and a robust
  854.       implementation SHOULD support the field as undistinguished octets.
  855.       The size is determined from the Length field.
  856.  
  857.       It is intended that only an authorized user will have correct site
  858.       specific information to make use of the Callback.  The
  859.       codification of the range of allowed usage of this field is
  860.       outside the scope of this specification.
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883. Simpson                  expires in six months                 [Page 15]
  884. DRAFT                      PPP LCP extensions                August 1993
  885.  
  886.  
  887. 2.4.  Compound-Frames
  888.  
  889.    Description
  890.  
  891.       This Configuration Option provides a method for an implementation
  892.       to send multiple PPP encapsulated packets within the same frame.
  893.       This option might be used for many diverse purposes, such as
  894.       savings on toll charges.
  895.  
  896.       Only those PPP Protocols which have determinate lengths or
  897.       integral length fields may be aggregated into a compound frame.
  898.  
  899.       When Compound-Frames is successfully negotiated, the sender MAY
  900.       add additional packets to the same frame.  Each packet is
  901.       immediately followed by another Protocol field, with its attendant
  902.       datagram.
  903.  
  904.       When padding is added to the end of the Information field, the
  905.       procedure described in Self-Describing-Padding is used.
  906.       Therefore, this option MUST be negotiated together with the Self-
  907.       Describing-Padding option.
  908.  
  909.       If the FCS-Alternatives option has been negotiated, self
  910.       describing padding MUST always be added.  That is, the final
  911.       packet MUST be followed by a series of octets, the first of which
  912.       contains the value one (1).
  913.  
  914.       On receipt, the first Protocol field is examined, and the packet
  915.       is processed as usual.  For those datagrams which have a
  916.       determinate length, the remainder of the frame is returned to the
  917.       demultiplexor.  Each succeeding Protocol field is processed as a
  918.       separate packet.  This processing is complete when a packet is
  919.       processed which does not have a determinate length, when the
  920.       remainder of the frame is empty, or when the Protocol field is
  921.       determined to have a value of one (1).
  922.  
  923.       The PPP Protocol value of one (1) is reserved as the Padding
  924.       Protocol.  Any following octets are removed as padding.
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938. Simpson                  expires in six months                 [Page 16]
  939. DRAFT                      PPP LCP extensions                August 1993
  940.  
  941.  
  942.    A summary of the Compound-Frames Option format is shown below.  The
  943.    fields are transmitted from left to right.
  944.  
  945.     0                   1
  946.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  947.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  948.    |     Type      |    Length     |
  949.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  950.  
  951.  
  952.    Type
  953.  
  954.       15
  955.  
  956.    Length
  957.  
  958.       2
  959.  
  960.  
  961. 2.4.1.  LCP considerations
  962.  
  963.    During initial negotiation, the Compound-Frames option can be used to
  964.    minimize the negotiation latency, by reducing the number of frames
  965.    exchanged.
  966.  
  967.    The first LCP Configure-Request packet is sent as usual in a single
  968.    frame, including the Self-Describing-Padding and Compound-Frames
  969.    options.
  970.  
  971.    The peer SHOULD respond with a Configure-Ack, followed in a compound
  972.    frame by its LCP Configure-Request, and any NCP Configure-Requests
  973.    desired.
  974.  
  975.    Upon receipt, the local implementation SHOULD process the Configure-
  976.    Ack as usual.  Since the peer has agreed to send compound frames, the
  977.    implementation MUST examine the remainder of the frame for additional
  978.    packets.  If the peer also specified the Self-Describing-Padding and
  979.    Compound-Frames options in its Configure-Request, the local
  980.    implementation SHOULD retain its Configure-Ack, and further NCP
  981.    configuration packets SHOULD be added to the return frame.
  982.  
  983.    Together with the peer's final return frame, the minimum number of
  984.    frames to complete configuration is 4.
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993. Simpson                  expires in six months                 [Page 17]
  994. DRAFT                      PPP LCP extensions                August 1993
  995.  
  996.  
  997. A.  Fast Frame Check Sequence (FCS) Implementation
  998.  
  999. A.1.  32-bit FCS Computation Method
  1000.  
  1001.    The following code provides a table lookup computation for
  1002.    calculating the 32-bit Frame Check Sequence as data arrives at the
  1003.    interface.
  1004.  
  1005.    /*
  1006.     * u32 represents an unsigned 32-bit number.  Adjust the typedef for
  1007.     * your hardware.
  1008.     */
  1009.    typedef unsigned long u32;
  1010.  
  1011.    static u32 fcstab_32[256] =
  1012.       {
  1013.       0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
  1014.       0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
  1015.       0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
  1016.       0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
  1017.       0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
  1018.       0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
  1019.       0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
  1020.       0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
  1021.       0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
  1022.       0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
  1023.       0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
  1024.       0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
  1025.       0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
  1026.       0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
  1027.       0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
  1028.       0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
  1029.       0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
  1030.       0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
  1031.       0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
  1032.       0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
  1033.       0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
  1034.       0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
  1035.       0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
  1036.       0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
  1037.       0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
  1038.       0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
  1039.       0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
  1040.       0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
  1041.       0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
  1042.       0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
  1043.       0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
  1044.       0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
  1045.  
  1046.  
  1047.  
  1048. Simpson                  expires in six months                 [Page 18]
  1049. DRAFT                      PPP LCP extensions                August 1993
  1050.  
  1051.  
  1052.       0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
  1053.       0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
  1054.       0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
  1055.       0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
  1056.       0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
  1057.       0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
  1058.       0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
  1059.       0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
  1060.       0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
  1061.       0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
  1062.       0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
  1063.       0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
  1064.       0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
  1065.       0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
  1066.       0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
  1067.       0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
  1068.       0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
  1069.       0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
  1070.       0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
  1071.       0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
  1072.       0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
  1073.       0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
  1074.       0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
  1075.       0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
  1076.       0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
  1077.       0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
  1078.       0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
  1079.       0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
  1080.       0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
  1081.       0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
  1082.       0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
  1083.       0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
  1084.       };
  1085.  
  1086.    #define PPPINITFCS32  0xffffffff   /* Initial FCS value */
  1087.    #define PPPGOODFCS32  0xdebb20e3   /* Good final FCS value */
  1088.  
  1089.    /*
  1090.     * Calculate a new FCS given the current FCS and the new data.
  1091.     */
  1092.    u32 pppfcs32(fcs, cp, len)
  1093.        register u32 fcs;
  1094.        register unsigned char *cp;
  1095.        register int len;
  1096.        {
  1097.        ASSERT(sizeof (u32) == 4);
  1098.        ASSERT(((u32) -1) > 0);
  1099.        while (len--)
  1100.  
  1101.  
  1102.  
  1103. Simpson                  expires in six months                 [Page 19]
  1104. DRAFT                      PPP LCP extensions                August 1993
  1105.  
  1106.  
  1107.            fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
  1108.  
  1109.        return (fcs);
  1110.        }
  1111.  
  1112.    /*
  1113.     * How to use the fcs
  1114.     */
  1115.    tryfcs32(cp, len)
  1116.        register unsigned char *cp;
  1117.        register int len;
  1118.    {
  1119.        u32 trialfcs;
  1120.  
  1121.        /* add on output */
  1122.        trialfcs = pppfcs32( PPPINITFCS32, cp, len );
  1123.        trialfcs ^= 0xffffffff;             /* complement */
  1124.        cp[len] = (trialfcs & 0x00ff);      /* Least significant byte first */
  1125.        cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
  1126.        cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
  1127.        cp[len+3] = ((trialfcs >> 8) & 0x00ff);
  1128.  
  1129.        /* check on input */
  1130.        trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
  1131.        if ( trialfcs == PPPGOODFCS32 )
  1132.            printf("Good FCS\n");
  1133.    }
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158. Simpson                  expires in six months                 [Page 20]
  1159. DRAFT                      PPP LCP extensions                August 1993
  1160.  
  1161.  
  1162. Security Considerations
  1163.  
  1164.    Security issues are briefly discussed in sections concerning the
  1165.    Callback Configuration Option.
  1166.  
  1167.  
  1168. References
  1169.  
  1170.    [1]   Simpson, W.A., "The Point-to-Point Protocol (PPP)", work in
  1171.          progress.
  1172.  
  1173.    [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC 1340,
  1174.          July 1992.
  1175.  
  1176.    [3]   Simpson, W.A., "PPP HLDC Framing", work in progress.
  1177.  
  1178.  
  1179. Acknowledgments
  1180.  
  1181.    The Identification feature was suggested by Bob Sutterfield (Morning
  1182.    Star Technologies).
  1183.  
  1184.    The Time-Remaining feature was suggested by Brad Parker (then of
  1185.    Cayman).
  1186.  
  1187.    Some of the original text for FCS-Alternatives was provided by Arthur
  1188.    Harvey (then of DEC).  The Null FCS was requested by Peter Honeyman
  1189.    (UMich).  The 32-bit FCS example code was provided by Karl Fox
  1190.    (Morning Star Technologies).
  1191.  
  1192.    Self-Describing-Padding was suggested and named by Fred Baker (ACC).
  1193.  
  1194.    Compound-Frames was suggested by Keith Sklower (Berkeley).
  1195.  
  1196.    Special thanks to Morning Star Technologies for providing computing
  1197.    resources and network access support for writing this specification.
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213. Simpson                  expires in six months                 [Page 21]
  1214. DRAFT                      PPP LCP extensions                August 1993
  1215.  
  1216.  
  1217. Chair's Address
  1218.  
  1219.    The working group can be contacted via the current chair:
  1220.  
  1221.       Fred Baker
  1222.       Advanced Computer Communications
  1223.       315 Bollay Drive
  1224.       Santa Barbara, California, 93111
  1225.  
  1226.       EMail: fbaker@acc.com
  1227.  
  1228.  
  1229. Editor's Address
  1230.  
  1231.    Questions about this memo can also be directed to:
  1232.  
  1233.       William Allen Simpson
  1234.       Daydreamer
  1235.       Computer Systems Consulting Services
  1236.       1384 Fontaine
  1237.       Madison Heights, Michigan  48071
  1238.  
  1239.       EMail: Bill.Simpson@um.cc.umich.edu
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268. Simpson                  expires in six months                 [Page 22]
  1269. DRAFT                      PPP LCP extensions                August 1993
  1270.  
  1271.  
  1272.                            Table of Contents
  1273.  
  1274.  
  1275.      1.     Additional LCP Packets ................................    1
  1276.         1.1       Identification ..................................    2
  1277.         1.2       Time-Remaining ..................................    5
  1278.  
  1279.      2.     Additional LCP Configuration Options ..................    8
  1280.         2.1       FCS-Alternatives ................................    9
  1281.            2.1.1  LCP considerations ..............................   10
  1282.            2.1.2  Null FCS ........................................   10
  1283.         2.2       Self-Describing-Padding .........................   12
  1284.         2.3       Callback ........................................   14
  1285.         2.4       Compound-Frames .................................   16
  1286.            2.4.1  LCP considerations ..............................   17
  1287.  
  1288.      APPENDICES ...................................................   18
  1289.  
  1290.      A.     Fast Frame Check Sequence (FCS) Implementation ........   18
  1291.         A.1       32-bit FCS Computation Method ...................   18
  1292.  
  1293.      SECURITY CONSIDERATIONS ......................................   21
  1294.  
  1295.      REFERENCES ...................................................   21
  1296.  
  1297.      ACKNOWLEDGEMENTS .............................................   21
  1298.  
  1299.      CHAIR'S ADDRESS ..............................................   22
  1300.  
  1301.      EDITOR'S ADDRESS .............................................   22
  1302.  
  1303.  
  1304.  
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.